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REMARKS 

Rejections 

Claims 1-6 and 41 were pending in this case and all stand rejected. The Examiner 
withdrew his earlier objections to the figures and the disclosure and to Claims 1 and 5 for 
informalities and also withdrew the rejection of Claims 4 and 41 under 35 U.S.C. §112. 

The only remaining rejections are the new rejections made by the Examiner in rejecting 
Claims 1, 3, and 5 and 6 under 35 U.S.C. §103 as being unpatentable over Linnartz in view Callway 
and further Claims 4 and 41 in view of Linnartz and Callway and further in view of "admitted prior 
art." 


Amendments 


Applicant has amended the claims herein. Claims 1 and 5, which are the two currently 
pending independent claims, have been amended to recite identically, see Claim 1, final clause, "the 
data being associated with the watermark and extending over a plurality of fields of the video 
signal ." (emphasis added.) This reads on the specification page 13, beginning line 7: 

In some embodiments the watermarking system carries 8-bits per 
frame; however only 4 bits are available for hashing seed purposes. . . For security 
reasons it is desirable to use a 64-bit seed and 64-bit tickets. Thus, these 
embodiments require a minimum of 16 frames with the actual number of frames 
dependent on the transport protocol employed based on the digital communication 
system design. 

Further, with respect to one embodiment on page 13, beginning line 23: 

Some embodiments also employ 16-bits per field when carrying the 
ticket on line 21. 

Therefore, it is desirable that the ticket is relatively long to ensure cryptographic 
security; 64-bits are suggested. Hence even if there are 16 ticket bits on horizontal line 21 of each 
video field, that requires at least four such video fields to carry the entire ticket. Of course, this is 
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because the ticket is a cryptographic value in some embodiments and a short cryptographic ticket 
(derived from a short seed) would be too easily broken. 

References 

Similarly, Linnartz suggests use of a relatively lengthy ticket, see Linnartz, column 6 
beginning line 17: 

A Copy-Control Ticket T which plays the role of a cryptographic 
counter. T is a small data field. . .T typically contains 40 to 1000 bits. 

Hence, Linnartz, similar to the present invention, recommends a relatively long ticket in 
terms of the number of bits. This is because Linnartz, as in accordance with the present invention, 
uses the ticket for cryptographic security. Linnartz also recommends putting the ticket in analog 
video in the vertical blanking intervals at page 6, lines 10-11. This is in the context of an analog 
video watermark, see Linnartz column 6, beginning line 8: 

If this concept is applied to video, an analogue watermark can for 
instance be combined with ticket, represented in Vertical Blanking Intervals. The 
digital watermark can be represented both in the MPEG PTY (Picture Type) 
sequence and in the pixel domain, the ticket can be stored in user data fields of a 
GOP (Group Of Pictures) header, (emphasis added.) 

Hence, Linnartz distinguishes between the analog watermark where the ticket is put in 
the vertical blanking intervals and the digital watermark (pixel domain) when the ticket is put in 
user data fields. This is, presumably, because in the video digital domain the vertical blanking 
intervals are often not recorded or even passed on and so are not suitable for carrying data. 

Linnartz emphasizes this use of digital video and the location of the ticket in other than 
blanking intervals in digital video at column 9, beginning line 6: 

The control pattern or ticket may be recorded along with the content 
information, or alternatively a separate location not directly accessible to a 
malicious party may be selected,' e.g., located in file headers or in the lead-in 
section of a CD or DVD . The copy-control ticket can be hidden in the MPEG 
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video stream In an embodiment this data is located in the GOP header . ; . 
(emphasis added.) 

Further, there is no reference in this part of Linnartz to use of the vertical blanking 
interval, since the vertical blanking interval is often not available for this purpose with digital video. 

The Examiner cited Callway as disclosing use of vertical blanking interval line 21 (the 
parental blocking horizontal line) for carrying data for copy control purposes. See Callway, column 
3, beginning line 38: 

If the video data is to be encoded, the horizontal sync lines 38 and 40 
and/or the vertical sync lines 36 and 34 would include the embedded data access 
parameters. For example, the vertical sync lines 34 and 36 may included 
embedded information that allows close caption to be employed on a television 
set. The vertical sync lines 34 and 36-also referred to as vertical blank 
intervals — may further store information that is referred to as teletext lines, which 
allow for additional information to be carried in the vertical sync lines 34 and 36. 

(Note that 38, 40, 34 and 36 are reference numbers in the Callway figures and not 
intended to be the numbers of the video horizontal scan lines themselves.) The embedded data 
access parameters 42 and 44 are the copy control information depicted in Callway Fig. 3 in the back 
porch of horizontal video line 38. In Callway as depicted in his Fig. 3, all of the data access 
parameters are carried in a single horizontal video line, hence in a single video field or frame. (In 
conventional TV, there are two interlaced fields in each video frame.) This is because the Callway 
copy control information is relatively simply, being intended merely to control copy or access. In 
that sense, these parameters are a code with an overt meaning and relatively few data bits are 
needed to carry the coded information which is limited to, for instance, see Callway, column 3, 
beginning line 2: 

The indication may be an indication that some form of protection is 
available (Eg. That the video data is encoded with Macrovision) or the indication 
may clearly define the particular type of protection. For example, the protection 
may be limited viewing options, parental control, copying restrictions, use 
restrictions of particular data. . . 
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Hence, in Callway the embedded data access parameters are a code which carries overt 
information and so the relatively simple code in Fig. 3 (in this case only two pulses 42, 44) is 
suitable. Clearly the data access parameters are carried in a single video frame or field. It is clear 
that Callaway in teaching these simple codes for access/copy control is content to restrict his 
embedded data access parameters to a single field or frame. While these parameters might be 
repeated in subsequent fields or frames, this would merely be a repetition of the same code and not 
represent additional data carried in subsequent fields or frames. 

Therefore, this Callway system is not suitable for use in accordance with the present 
invention, or in combination with the Linnartz approach. In Linnartz, as in accordance with the 
present invention, the ticket is preferably relatively long, e.g. the suggested 64-bits in the present 
specification, to ensure cryptographic security. Of course, no such consideration is the case in 
Callway since no cryptographic or other security feature in terms of the data itself is present in 
Callway. 

Additionally, Linnartz while suggesting use of a relatively long ticket, makes no 
recommendation as how this is accomplished in conjunction with analog watermarks and analog 
video. The bulk of the Linnartz disclosure is of digital video. It is pointed out in Linnartz at several 
locations that the control pattern (which is the ticket) is used in the digital domain and put in user 
data fields, as quoted above. The only description in Linnartz of using the ticket in the analog video 
context is as quoted above at column 6, lines 8-11. Moreover the actual definition of the ticket in 
Linnartz does not suggest it actually has a an analog counterpart, see the definition of the ticket at 
column 6, beginning line 18: 

T is a small data field that is present in the data headers, e.g. added to 
the signal in a similar manner as said DCC copy control bits, (emphasis added.) 

This has no particular relevance to the analog video domain where there are no data 
headers and no data fields per se. 

Patentability of the Claims 
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It is respectfully submitted that present Claim 1 as amended distinguishes over the two 
cited references, even in combination, by reciting "providing data in a predetermined video line of 
the video signal in the vertical blanking interval carrying parental blocking data, the data being 
associated with the watermark and extending over a plurality of fields of the video signal ." 
(emphasis added.) Linnartz has not described how his ticket would be provided in the vertical 
blanking intervals if the ticket is for instance 40 or more bits long. Instead Linnartz describes, in the 
digital domain, putting the ticket into data headers which have no corresponding place in analog 
video. Callway, while using the parental blocking horizontal line of the vertical blanking interval, 
puts the entire data access parameters in a single video field since the parameters are relatively 
short, for instance the two pulses 42, 44 shown in Callway Fig. 3. 

Hence it is respectively submitted that the Examiner's combination of the two references 
fails to meet Claim 1, first because it would not be obvious to one of ordinary skill in the art to use 
the Callway approach in conjunction with Linnartz. This is because Callway is strictly an analog 
video approach, while Linnartz is essentially operating on digital video and only mentions use of 
analog video in one place. Hence one would not necessarily look to Callway to solve the technical 
problem of Linnartz as to where to put the ticket. Second even if the combination of references 
were adequately motivated, there is no suggestion in either reference to do as now recited in Claim 
1, "the data being associated with the watermark and extending over a plurality of fields of the 
video signal." Hence the method in accordance with Claim 1 has the advantage of operating in the 
analog video domain and providing a cryptographic type ticket in the form of data which is long 
enough to provide adequate security. In contrast, a ticket which occupies only single field as taught 
by Callway would have almost no security value and hence would not be useful. 

Independent Claim 5 has been amended identically to Claim 1 and hence distinguishes 
over the references for at least the same reasons as Claim 1. 

New Claims 42 and 43 have been added dependent respectively on Claims 1 and 5 but 
otherwise are identical in reciting "the data extends over at least four fields of the video signal and 
includes at least 64 bits." This reads on the specification page 13, lines 7-23 (also quoted above) 
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calling for a 64-bit ticket with 1 6 bits per video field. Claims 42 and 43 are allowable for at least 
for the same reasons as respectively their base claims. 
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Conclusion 

In view of the above, all presently pending Claims 1-6 and 41-43 in this application are 
believed to be in immediate condition for allowance. Accordingly, the Examiner is respectfully 
requested to withdraw the outstanding rejection of the claims and to pass this application to issue. If 
it is determined that a telephone conference would expedite the prosecution of this application, the 
Examiner is invited to telephone the undersigned at the number given below. 

In the event the U.S. Patent and Trademark office determines that an extension and/or 
other relief is required, applicant petitions for any required relief including extensions of time and 
authorizes the Commissioner to charge the cost of such petitions and/or other fees due in connection 
with the filing of this document to Deposit Account No. 03-1952 referencing docket no. 
136922001900. However, the Commissioner is not authorized at this time to charge the cost of the 
issue fee to the Deposit Account. 

Dated: January 10, 2005 Respectfully submitted, 

Norman R. Klivans 

Registration No.: 33,003 
MORRISON & FOERSTER LLP 
755 Page Mill Road 
Palo Alto, California 94304 
(650) 813-5850 
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